fix: block SSRF via IPv6 addresses embedding a non-global IPv4 (NAT64/IPv4-compatible)#6347
Open
adilburaksen wants to merge 2 commits into
Open
fix: block SSRF via IPv6 addresses embedding a non-global IPv4 (NAT64/IPv4-compatible)#6347adilburaksen wants to merge 2 commits into
adilburaksen wants to merge 2 commits into
Conversation
load_web_page vets resolved addresses with `not address.is_global`, but `is_global` on an IPv6 address does not reflect the embedded IPv4 target for NAT64 (`64:ff9b::/96`) and IPv4-compatible (`::a.b.c.d`) addresses. On a network with NAT64 (e.g. IPv6-only / DNS64 clusters), a URL like `http://[64:ff9b::169.254.169.254]/` is treated as global and reaches the internal 169.254.169.254 metadata endpoint. Extract the embedded IPv4 and reject it when it is not globally routable.
Contributor
Author
|
Note: the same |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
load_web_pagevets every resolved address with_is_blocked_address, which currently rejects an address only whennot address.is_global. For IPv6,is_globalon the outer address does not reflect the reachability of an embedded IPv4 target:is_global64:ff9b::169.254.169.254(NAT64, RFC 6052)True169.254.169.254::169.254.169.254(IPv4-compatible)True169.254.169.254On a network with NAT64 (common in IPv6-only / DNS64 clusters, e.g. GKE), a URL such as
http://[64:ff9b::169.254.169.254]/computeMetadata/v1/passes theis_globalcheck and isrouted by NAT64 to the internal
169.254.169.254metadata endpoint — an SSRF that can reach thecloud metadata server / other link-local and private ranges.
The existing IPv4-mapped (
::ffff:a.b.c.d) and 6to4 (2002::/16) forms are already reported asnon-global by
ipaddress, so they were handled; NAT64 and the deprecated IPv4-compatible form arethe gaps.
Fix
Add
_embedded_ipv4()which extracts the embedded IPv4 for IPv4-mapped, 6to4, NAT64(
64:ff9b::/96) and IPv4-compatible addresses, and reject the outer address when the embeddedIPv4 is not globally routable. Public NAT64 targets (e.g.
64:ff9b::8.8.8.8) remain allowed, sothere is no over-blocking of legitimate destinations.
Scope / honesty
Reaching the internal target requires the deployment network to actually route the embedded form
(NAT64 present, or a stack that routes IPv4-compatible IPv6). Where it doesn't route, this is
defense-in-depth completing the existing SSRF filter; where NAT64 is present it closes a real
metadata-SSRF path. Added regression tests for both forms.